Mechanism for automatic adjustment of virtual machine storage

ABSTRACT

A mechanism for automatic adjustment of virtual machine (VM) storage is disclosed. A method of embodiments of the invention includes stopping, by a host computing device, a virtual machine (VM) hosted by the host computing device from running upon detecting a write error due to lack of storage on the VM, communicating, by the host computing device, an out-of-storage notification from a hypervisor of the host computing device to a host management agent, and sending, by the host computing device, data associated with the out-of storage notification and the VM to a host controller that manages the host computing device, wherein the host controller causes storage for the VM to be increased.

TECHNICAL FIELD

The embodiments of the invention relate generally to virtual machinesystems and, more specifically, relate to a mechanism for automaticadjustment of virtual machine storage.

BACKGROUND

In computer science, a virtual machine (VM) is a portion of softwarethat, when executed on appropriate hardware, creates an environmentallowing the virtualization of an actual physical computer system. EachVM may function as a self-contained platform, running its own operatingsystem (OS) and software applications (processes). Typically, a virtualmachine monitor (VMM) manages allocation and virtualization of computerresources and performs context switching, as may be necessary, to cyclebetween various VMs.

A host machine (e.g., computer or server) is typically enabled tosimultaneously run multiple VMs, where each VM may be used by a local orremote user. The host machine allocates a certain amount of the host'sresources to each of the VMs. Each VM is then able to use the allocatedresources to execute applications, including operating systems known asguest operating systems. The VMM virtualizes the underlying hardware ofthe host machine or emulates hardware devices, making the use of the VMtransparent to the guest operating system or the the user of the VM.

Recently, solutions providing centralized hosting for VMs that run(virtual) desktops have been developed. Such solutions consist ofcentralized servers that are partitioned into multiple VMs that host theVMs, thereby providing a desktop for each user. The centralized hostingprovides the manageability of sever-based computing, while the dedicatedenvironment provides the flexibility and compatibility with applicationsthat a desktop enables.

However, one problem that arises with centralized hosting of VMs is thatit demands large allocation of storage for all of the VMs. Such largeallocation of storage is especially painful when there are many VMsbeing hosted, a common scenario in desktop virtualization. In order todeal with this problem, sparse storage allocation solutions have beendeveloped to address the problem.

With a sparse storage allocation solution, each VM is allocated someminimum storage space out of the shared pool of storage. The storageallocation per VM is usually a small amount that is allocated on-demand;rather than allocating to each VM the maximum amount of storage that theVM may use. Virtualization systems require storage allocation in thissparse manner in order to conserve disk space for use only by VM systemsthat require the storage.

During VM execution, more disk space is generally allocated on-the-flyas needed. However, under this system, a VM will most likely reach acertain point where it has utilized all available disk space that it hasbeen allocated. At this point, conventional systems require some sort ofhuman interaction to stop the VM, adjust the storage allocation to theVM, and may even require restarting the VM. Furthermore, if the VM isnot stopped when it runs out of storage, then additional problems mayoccur, such as guest fs confusion/recovery, high CPU usage, and so on.Such manual interaction and other resulting problems are costly in termsof overhead and time-consuming in terms of performance. As such, amechanism for automatic adjustment of virtual machine storage withoutmanual user intervention would be beneficial.

BRIEF DESCRIPTION OF THE DRAWINGS

The invention will be understood more fully from the detaileddescription given below and from the accompanying drawings of variousembodiments of the invention. The drawings, however, should not be takento limit the invention to the specific embodiments, but are forexplanation and understanding only.

FIG. 1 is a block diagram of an exemplary network architecture in whichembodiments of the present invention may operate;

FIG. 2 is a block diagram of a detailed view of a virtualizationenvironment for automatic storage adjustment for virtual machines;

FIG. 3 is a flow diagram illustrating a method for automatic adjustmentof virtual machine storage; and

FIG. 4 illustrates a block diagram of one embodiment of a computersystem.

DETAILED DESCRIPTION

Embodiments of the invention provide a mechanism for automaticadjustment of virtual machine (VM) storage. A method of embodiments ofthe invention includes stopping, by a host computing device, a virtualmachine (VM) hosted by the host computing device from running upondetecting a write error due to lack of storage on the VM, communicating,by the host computing device, an out-of-storage notification from ahypervisor of the host computing device to a host management agent, andsending, by the host computing device, data associated with the out-ofstorage notification and the VM to a host controller that manages thehost computing device, wherein the host controller causes storage forthe VM to be increased.

In the following description, numerous details are set forth. It will beapparent, however, to one skilled in the art, that the present inventionmay be practiced without these specific details. In some instances,well-known structures and devices are shown in block diagram form,rather than in detail, in order to avoid obscuring the presentinvention.

Some portions of the detailed descriptions which follow are presented interms of algorithms and symbolic representations of operations on databits within a computer memory. These algorithmic descriptions andrepresentations are the means used by those skilled in the dataprocessing arts to most effectively convey the substance of their workto others skilled in the art. An algorithm is here, and generally,conceived to be a self-consistent sequence of steps leading to a desiredresult. The steps are those requiring physical manipulations of physicalquantities. Usually, though not necessarily, these quantities take theform of electrical or magnetic signals capable of being stored,transferred, combined, compared, and otherwise manipulated. It hasproven convenient at times, principally for reasons of common usage, torefer to these signals as bits, values, elements, symbols, characters,terms, numbers, or the like.

It should be borne in mind, however, that all of these and similar termsare to be associated with the appropriate physical quantities and aremerely convenient labels applied to these quantities. Unlessspecifically stated otherwise, as apparent from the followingdiscussion, it is appreciated that throughout the description,discussions utilizing terms such as “sending”, “receiving”, “attaching”,“forwarding”, “caching”, or the like, refer to the action and processesof a computer system, or similar electronic computing device, thatmanipulates and transforms data represented as physical (electronic)quantities within the computer system's registers and memories intoother data similarly represented as physical quantities within thecomputer system memories or registers or other such information storage,transmission or display devices.

The present invention also relates to an apparatus for performing theoperations herein. This apparatus may be specially constructed for therequired purposes, or it may comprise a general purpose computerselectively activated or reconfigured by a computer program stored inthe computer. Such a computer program may be stored in a computerreadable storage medium, such as, but not limited to, any type of diskincluding floppy disks, optical disks, CD-ROMs, and magnetic-opticaldisks, read-only memories (ROMs), random access memories (RAMs), EPROMs,EEPROMs, magnetic or optical cards, or any type of media suitable forstoring electronic instructions, each coupled to a computer system bus.

The algorithms and displays presented herein are not inherently relatedto any particular computer or other apparatus. Various general purposesystems may be used with programs in accordance with the teachingsherein, or it may prove convenient to construct more specializedapparatus to perform the required method steps. The required structurefor a variety of these systems will appear as set forth in thedescription below. In addition, the present invention is not describedwith reference to any particular programming language. It will beappreciated that a variety of programming languages may be used toimplement the teachings of the invention as described herein.

The present invention may be provided as a computer program product, orsoftware, that may include a machine-readable medium having storedthereon instructions, which may be used to program a computer system (orother electronic devices) to perform a process according to the presentinvention. A machine-readable medium includes any mechanism for storingor transmitting information in a form readable by a machine (e.g., acomputer). For example, a machine-readable (e.g., computer-readable)medium includes a machine (e.g., a computer) readable storage medium(e.g., read only memory (“ROM”), random access memory (“RAM”), magneticdisk storage media, optical storage media, flash memory devices, etc.),a machine (e.g., computer) readable transmission medium (non-propagatingelectrical, optical, or acoustical signals), etc.

Embodiments of the invention provide a mechanism for automaticadjustment of virtual machine (VM) storage. Some virtualization systemsallocate minimal storage to VMs in order to save storage space on thedisk. Consequently, during VM execution, more disk space may be neededby a VM, which will be allocated to the VM on-the-fly as needed.Embodiments of the invention eliminate any human interaction previouslyrequired to provide this additional storage allotment to VMs.Specifically, embodiments of the invention determine when a VM hasreached a threshold storage utilization, stop the VM, adjust storageallocation for the VM, and resume the VM, all in an automated mannerwhich precludes manual user intervention.

FIG. 1 illustrates an exemplary network architecture 100 in whichembodiments of the present invention may operate. The networkarchitecture 100 includes a cluster of host machines 109 coupled to oneor more clients 101 over a network 102. The network 102 may be a privatenetwork (e.g., a local area network (LAN), a wide area network (WAN),intranet, etc.) or a public network (e.g., the Internet). In oneembodiment, host machines 109 may be known as host computing devicesthat include at least a processor and a memory. Each host machine 109may be a server computer that includes one or more virtual machines(VMs) 131. In some embodiments, clients 101 may be hosted directly byhost machine 109 as a local client on host machine 109.

The host machines 109 are also coupled to data storage 105. The datastorage 105 includes one or more mass storage devices (e.g., disks),which form a storage pool shared by all of the host machines 109. In oneembodiment, the data storage 105 is a network-based storage system, suchas network attached storage (NAS), storage area networks (SANs), orother storage systems. In one embodiment, data storage 105 may becoupled to a storage manager 103 that performs managerial functions forthe data storage 105. The storage manager 103 may reside on a dedicatedmachine or share the machine with other components of system 100.

The clients 101 may include computing devices that have a wide range ofprocessing capabilities. Some of the clients 101 may be thin clients,which have limited processing and memory capacities. For example, a thinclient may a laptop computer, cellular phone, personal digital assistant(PDA), a re-purposed desktop computer, etc. Some of the clients 101 maybe thick (fat) clients, which have powerful CPUs and large memory. Forexample, a thick client may be a dual-core or multi-core computer,workstation, graphics workstation, etc. The client 101 may run clientapplications such as a Web browser and a graphic user interface (GUI).The client 101 may also run other client applications, which receivemultimedia data streams or other data from one or more host computers109 and re-direct the received data to a local display or other userinterface.

As mentioned previously, each host machine 109 may run one or more VMs131. Each VM 131 runs a guest operating system (OS) that may bedifferent from one VM to another. The guest OS may include MicrosoftWindows, Linux, Solaris, Mac OS, etc. Furthermore, each host machine 109may include a hypervisor 132 that emulates the underlying hardwareplatform for the VMs 131 that it hosts. The hypervisor 132 may also beknown as a virtual machine monitor (VMM) or a kernel-based hypervisor.In some embodiments, the hypervisor 132 is part of a host operatingsystem.

Each VM 131 can be accessed by one or more of the clients 101 over thenetwork 102. In one scenario, each VM 131 provides a virtual desktop forthe client 101. From the user's point of view, the virtual desktopfunctions as a physical desktop (e.g., a personal computer) and isindistinguishable from a physical desktop.

The host machines 109 may be managed by a host controller 107. The hostcontroller 107 may be a separate machine coupled to the host machines109 directly or via a network. Alternatively, the host controller 107may be part of one of the host machines 109. The host controller 107 mayadd a VM 131, delete a VM 131, balance the load on the cluster of hostmachines 109, provide directory service to the VMs 131, and performother managerial functions. Additionally, each host machine 109 includesa host management agent 135. The host management agent is responsiblefor managing all of the activities related to VM maintenance, includingresource allocation (e.g., storage, RAM, networking, etc.), VMinitialization, VM monitoring, VM termination, controlling some dynamiccapabilities of the VM, and so on.

According to one embodiment of the present invention, each VM 131, uponinitialization, is allocated some minimum storage space out of theshared pool of storage 105. It should be noted that although embodimentsof the invention are described in terms of a shared pool of storage, itis envisioned that embodiments of the invention may also be equallyapplied to local or remote non-shared storage architectures. The storageallocation per VM 131 is typically a sparse amount that is allocatedon-demand. In such a system a VM 131 is not allocated the maximum amountof storage 105 that the VM may use. Virtualization systems requirestorage allocation in this sparse manner in order to conserve disk spacefor use only by VM systems that truly require the storage. During VMexecution, more disk space is generally allocated from the sharedstorage pool 105 on-the-fly and as needed. However, previous techniquesto handle this additional allotment of storage to a VM were not doneautomatically and consequently required some sort of manual interventionby a human.

In one embodiment of the invention, when a VM 131 fully utilizes itscurrent storage allotment, a fault (write error) is generated due to thelack of storage space. An exit from the VM 131 is made upon the writerequest and resulting fault, and the write-error is then seen by thehypervisor 132. The hypervisor 132 examines an ID of the fault anddetermines that the fault was caused by the out-of-storage write error(in cases of an actual out-of-storage error). Subsequently, thehypervisor 132 sends an out-of-storage notification identifying theparticular VM 131, and in some embodiments the faulting storage, to thehost management agent 135 on the host machine 109. In one embodiment,the out-of-storage notification is provided to the host management agent135 via an application programming interface (API).

At this point, the host management agent 135 sends the data receivedfrom the hypervisor 132, including the out-of-storage notification andthe VM 131 identification, to the host controller 107. In turn, the hostcontroller 107 generates a request to increase the storage allotmentfrom the shared storage pool 105 to send to a storage manager of theshared storage pool 105. In one embodiment, the storage manager may bethe central storage manager 103 previously described above, or it may bea storage pool manager enabled in one of the host machines 109 (notshown) or in the host controller 107. The storage manager will thenallot additional storage for the VM 131 and send a message back to thehost controller 107 that the VM 131 may resume operations. This messageis propagated to the host management agent 135 that originated therequest, which then notifies the hypervisor 132 and it causes the VM 131to be re-activated. This notification between the host management agent135 and the hypervisor 132 may take place utilizing another API.

FIG. 2 illustrates a block diagram of a detailed view of avirtualization environment 200 for automatic storage adjustment for VMs.Virtualization environment 200 includes a host machine 210, a hostcontroller 220, a storage manager 230, and data storage 235. In oneembodiment, these components are the same as host machine 109, hostcontroller 107, storage manager 103, and data storage 105 described withrespect to FIG. 1.

Host machine 210 hosts a plurality of VMs 212 that are virtualized byhypervisor 214. Host machine 210 also includes a host management agent216 connected to hypervisor 214 via a monitor channel 215. According toone embodiment of the present invention, upon initialization each VM 212is allocated some minimum storage space out of the shared pool ofstorage 235. As the VM 212 is not allocated its maximum amount ofstorage that it may use, it will typically require additional storageallocation at a later time when it has used its current storageallotment. In one embodiment, when the VM 212 utilizes its currentstorage allotment, a write error occurs on the VM 212 due to the lack ofspace and is, in turn, detected by the hypervisor 214.

Subsequently, the hypervisor 214 sends an out-of-storage notificationidentifying the particular VM 212, and in some cases the faultingstorage, to the host management agent 216. The out-of storagenotification is sent to the host management agent 216 via a monitorchannel 215 that communicably couples the hypervisor 214 and the hostmanagement agent 216. In one embodiment, the out-of-storage notificationis provided via an API, as previously discussed.

At this point, the host management agent 216 sends the data receivedfrom the hypervisor 214, including the out-of-storage notification andthe VM 212 identification (and possibly the identification of thefaulting storage), to the host controller 220. In turn, the hostcontroller 220 generates a request to increase the storage allocationfor the VM 212 from the shared storage pool 235. The request is sent bythe host controller 220 to a storage manager 230 of the shared storagepool 235. In one embodiment, the storage manager 230 may be a centralstorage manager associated with the data storage cluster 235 or astorage pool manager enabled in the host machine 210 (not shown).

The storage manager 230 then allocates additional storage for the VM 212and sends a message back to the host controller 220 indicating that theVM 212 may be resumed. This message is propagated to the host managementagent 216 that originated the request, which then notifies thehypervisor 214 via the monitor channel 215 that the VM 212 may bereactivated. This notification between the host management agent 216 andthe hypervisor 214 may take place via another API.

FIG. 3 is a flow diagram illustrating a method 300 for automaticadjustment of VM storage according to an embodiment of the invention.Method 300 may be performed by processing logic that may comprisehardware (e.g., circuitry, dedicated logic, programmable logic,microcode, etc.), software (such as instructions run on a processingdevice), or a combination thereof. In one embodiment, method 300 isperformed by the various components of virtualization environment 200described with respect to FIG. 2.

Method 300 begins at block 310 where a hypervisor detects a write errordue to a lack of storage on a VM that it hosts. At block 320, thehypervisor sends an out-of-storage notification to a host managementagent via a monitor channel communicably coupling the two components. Inone embodiment, an API is used to communication the out-of-storagenotification between the hypervisor and the host management agent. Thehost management agent then sends data related to the receivedout-of-storage notification and associated VM to a host controller atblock 330.

Subsequently, at block 340, the host controller generates and sends arequest to increase the storage allotment for the VM to a storagemanager of a shared storage pool. The storage pool may be shared amongstmany VMs and VM host machines. As mentioned above, although embodimentsof the invention are described in terms of a shared pool of storage, itis envisioned that embodiments of the invention may also be equallyapplied to local or remote non-shared storage architectures. In oneembodiment, the storage manager utilizes the request sent from the hostcontroller to allocate additional storage for the VM according to anynumber of storage allotment techniques, which are outside of the scopeof embodiments of the invention. At block 350, the host controllerreceives confirmation of the increased storage allotment for the VM fromthe storage manager. The host controller then propagates thisconfirmation of the increased storage allotment for the VM to the hostmanagement agent at block 360.

The host management agent in turn notifies the hypervisor, via themonitor channel, that the VM can be resumed as the VM's storageallotment has been increased. In one embodiment, another API is used tocommunicate the increased storage notification between the hypervisorand the host management agent at block 370. Lastly, at block 380, thehypervisor causes the VM to be resumed, which now can operate correctlywith its increased storage allotment. It is important to note thatmethod 300 allows storage for a VM to be adjusted automatically withoutany manual user intervention.

FIG. 4 illustrates a diagrammatic representation of a machine in theexemplary form of a computer system 400 within which a set ofinstructions, for causing the machine to perform any one or more of themethodologies discussed herein, may be executed. In alternativeembodiments, the machine may be connected (e.g., networked) to othermachines in a LAN, an intranet, an extranet, or the Internet. Themachine may operate in the capacity of a server or a client machine in aclient-server network environment, or as a peer machine in apeer-to-peer (or distributed) network environment. The machine may be apersonal computer (PC), a tablet PC, a set-top box (STB), a PersonalDigital Assistant (PDA), a cellular telephone, a web appliance, aserver, a network router, switch or bridge, or any machine capable ofexecuting a set of instructions (sequential or otherwise) that specifyactions to be taken by that machine. Further, while only a singlemachine is illustrated, the term “machine” shall also be taken toinclude any collection of machines that individually or jointly executea set (or multiple sets) of instructions to perform any one or more ofthe methodologies discussed herein.

The exemplary computer system 400 includes a processing device 402, amain memory 404 (e.g., read-only memory (ROM), flash memory, dynamicrandom access memory (DRAM) (such as synchronous DRAM (SDRAM) or RambusDRAM (RDRAM), etc.), a static memory 406 (e.g., flash memory, staticrandom access memory (SRAM), etc.), and a data storage device 418, whichcommunicate with each other via a bus 430.

Processing device 402 represents one or more general-purpose processingdevices such as a microprocessor, central processing unit, or the like.More particularly, the processing device may be complex instruction setcomputing (CISC) microprocessor, reduced instruction set computer (RISC)microprocessor, very long instruction word (VLIW) microprocessor, orprocessor implementing other instruction sets, or processorsimplementing a combination of instruction sets. Processing device 402may also be one or more special-purpose processing devices such as anapplication specific integrated circuit (ASIC), a field programmablegate array (FPGA), a digital signal processor (DSP), network processor,or the like. The processing device 402 is configured to execute theprocessing logic 426 for performing the operations and steps discussedherein.

The computer system 400 may further include a network interface device408. The computer system 400 also may include a video display unit 410(e.g., a liquid crystal display (LCD) or a cathode ray tube (CRT)), analphanumeric input device 412 (e.g., a keyboard), a cursor controldevice 414 (e.g., a mouse), and a signal generation device 416 (e.g., aspeaker).

The data storage device 418 may include a machine-accessible storagemedium 428 on which is stored one or more set of instructions (e.g.,software 422) embodying any one or more of the methodologies offunctions described herein. The software 422 may also reside, completelyor at least partially, within the main memory 404 and/or within theprocessing device 402 during execution thereof by the computer system400; the main memory 404 and the processing device 402 also constitutingmachine-accessible storage media. The software 422 may further betransmitted or received over a network 420 via the network interfacedevice 408.

The machine-readable storage medium 428 may also be used to storedinstructions to perform automatic adjustment of VM storage, such as thatperformed by method 300 described with respect to FIG. 3, and/or asoftware library containing methods that call the above applications.While the machine-accessible storage medium 428 is shown in an exemplaryembodiment to be a single medium, the term “machine-accessible storagemedium” should be taken to include a single medium or multiple media(e.g., a centralized or distributed database, and/or associated cachesand servers) that store the one or more sets of instructions. The term“machine-accessible storage medium” shall also be taken to include anymedium that is capable of storing, encoding or carrying a set ofinstruction for execution by the machine and that cause the machine toperform any one or more of the methodologies of the present invention.The term “machine-accessible storage medium” shall accordingly be takento include, but not be limited to, solid-state memories, and optical andmagnetic media.

Whereas many alterations and modifications of the present invention willno doubt become apparent to a person of ordinary skill in the art afterhaving read the foregoing description, it is to be understood that anyparticular embodiment shown and described by way of illustration is inno way intended to be considered limiting. Therefore, references todetails of various embodiments are not intended to limit the scope ofthe claims, which in themselves recite only those features regarded asthe invention.

1. A computer-implemented method, comprising: stopping, by a hostcomputing device, a virtual machine (VM) hosted by the host computingdevice from running upon detecting a write error due to lack of storageon the VM; communicating, by the host computing device, anout-of-storage notification from a hypervisor of the host computingdevice to a host management agent; and sending, by the host computingdevice, data associated with the out-of storage notification and the VMto a host controller that manages the host computing device, wherein thehost controller causes storage for the VM to be increased.
 2. The methodof claim 1, wherein the out-of storage notification is communicated fromthe hypervisor to the host management agent via a monitor channelcommunicably coupling the hypervisor and the host management agent. 3.The method of claim 1, wherein the out-of storage notification iscommunicated between the hypervisor and the host management agentutilizing an application programming interface (API).
 4. The method ofclaim 1, further comprising: receiving, by the host management agent,confirmation of increased storage allotment for the VM from the hostcontroller; notifying, by the host management agent, the hypervisor thatit can resume the VM due to the increased storage allotment for the VM;and causing, by the hypervisor, the VM to be resumed upon receiving thenotification that it can resume the VM from the host management agent.5. The method of claim 4, wherein the host controller receives theconfirmation of increased storage allotment for the VM from a storagemanager subsequent to the storage manager increasing a storage allotmentfor the VM in response to a request from the host controller.
 6. Themethod of claim 5, wherein the storage manager is at least one of acentral storage manager that is part of a shared storage pool and astorage pool manager enabled in the host computing device.
 7. The methodof claim 4, wherein the notification from the host management agent tothe hypervisor that it can resume the VM is sent via a monitor channelcommunicably coupling the hypervisor and the host management agent. 8.The method of claim 4, wherein the notification from the host managementagent to the hypervisor that it can resume the VM is sent utilizinganother application programming interface (API).
 9. A system,comprising: a memory; a processor, communicably coupled to the memory;one or more virtual machines (VMs) executed from the processor and thememory; a hypervisor communicably coupled to the one or more VMs inorder to manage the one or more VMs under a kernel-based virtualizationmodel, the hypervisor operable to: detect a write error at a VM of theone or more VMs due to a lack of storage at the VM; stop the VM fromrunning; and generate an out-of-storage notification includinginformation identifying the VM producing the write error; and a hostmanagement agent communicably coupled to the hypervisor, the hostmanagement agent operable to: receive the out-of-storage notificationfrom the hypervisor; and send data associated with the out-of storagenotification and the identified VM to a host controller of the system,wherein the host controller causes storage for the VM to be increased bysending a request to increase storage for the VM.
 10. The system ofclaim 9, wherein the out-of storage notification is communicated fromthe hypervisor to the host management agent via a monitor channelcommunicably coupling the hypervisor and the host management agent whileutilizing an application programming interface (API).
 11. The system ofclaim 9, wherein the host management agent is further operable to:receive confirmation of increased storage allotment for the VM from thehost controller; and notify the hypervisor that it can resume the VM dueto the increased storage allotment for the VM.
 12. The system of claim11, wherein the hypervisor is further operable to cause the VM to resumeupon receiving the notification that it can resume the VM from the hostmanagement agent.
 13. The system of claim 11, wherein the hostcontroller receives the confirmation of increased storage allotment forthe VM from a storage manager subsequent to the storage managerincreasing a storage allotment for the VM in response to the requestfrom the host controller.
 14. The system of claim 13, wherein thestorage manager is at least one of a central storage manager that ispart of a shared storage pool and a storage pool manager enabled in thesystem.
 15. The system of claim 11, wherein the notification from thehost management agent to the hypervisor that it can resume the VM issent via a monitor channel communicably coupling the hypervisor and thehost management agent while utilizing another application programminginterface (API).
 16. A non-transitory machine-readable storage mediumincluding instructions that, when accessed by a machine, cause themachine to perform operations comprising: stopping a virtual machine(VM) hosted by a host computing device from running upon detecting awrite error due to lack of storage on the VM; communicating anout-of-storage notification from a hypervisor of the host computingdevice to a host management agent; and sending data associated with theout-of storage notification and the VM to a host controller that managesthe host computing device, wherein the host controller causes storagefor the VM to be increased.
 17. The non-transitory machine-readablestorage medium of claim 16, wherein the out-of storage notification iscommunicated from the hypervisor to the host management agent via amonitor channel communicably coupling the hypervisor and the hostmanagement agent while utilizing an application programming interface(API).
 18. The non-transitory machine-readable storage medium of claim16, wherein the instructions, when accessed by a machine, cause themachine to perform further operations comprising: receiving, by the hostmanagement agent, confirmation of increased storage allotment for the VMfrom the host controller; notifying, by the host management agent, thehypervisor that it can resume the VM due to the increased storageallotment for the VM; and causing, by the hypervisor, the VM to beresumed upon receiving the notification that it can resume the VM fromthe host management agent.
 19. The non-transitory machine-readablestorage medium of claim 18, wherein the host controller receives theconfirmation of increased storage allotment for the VM from a storagemanager subsequent to the storage manager increasing a storage allotmentfor the VM in response to a request from the host controller.
 20. Thenon-transitory machine-readable storage medium of claim 18, wherein thenotification from the host management agent to the hypervisor that itcan resume the VM is sent via a monitor channel communicably couplingthe hypervisor and the host management agent while utilizing anotherapplication programming interface (API).